home *** CD-ROM | disk | FTP | other *** search
- Date: Tue, 5 Apr 94 04:30:12 PDT
- From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu>
- Errors-To: Ham-Digital-Errors@UCSD.Edu
- Reply-To: Ham-Digital@UCSD.Edu
- Precedence: Bulk
- Subject: Ham-Digital Digest V94 #98
- To: Ham-Digital
-
-
- Ham-Digital Digest Tue, 5 Apr 94 Volume 94 : Issue 98
-
- Today's Topics:
- Baycom modem and AMTOR?
- CDE antenna rotor
- Heathkit HD-15 Phonepatch Manual?
- JNOS and SAM
- MFJ 120C & Netrom
- Unknown RTTY mode
-
- Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu>
- Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu>
- Problems you can't solve otherwise to brian@ucsd.edu.
-
- Archives of past issues of the Ham-Digital Digest are available
- (by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital".
-
- We trust that readers are intelligent enough to realize that all text
- herein consists of personal comments and does not represent the official
- policies or positions of any party. Your mileage may vary. So there.
- ----------------------------------------------------------------------
-
- Date: Tue, 5 Apr 94 12:52:58 +0400
- From: ihnp4.ucsd.edu!agate!howland.reston.ans.net!pipex!uknet!EU.net!news.eunet.fi!news.spb.su!satisfy.kiae.su!kiae!relcom!demos1!dnews-server@network.ucsd.edu
- Subject: Baycom modem and AMTOR?
- To: ham-digital@ucsd.edu
-
- Does anyone have the info about the possibility to
- operate AMTOR with a simple modem in "Baycom" style.
- Here is home made modem based on TCM3105 with an
- external modulator (for 300 baud) on 2 IC's and an
- active filters on 386/7 dx 40mHz at clone.
- It's working well PR with software Baycom V1.5
- and RTTY with Hamcomm V2.1, but i am still looking
- for any other software, which allow to operate with a
- "normal" terminal program, such a SP,GP... or in any
- other mode (AMTOR, PACTOR)
- I can't find this info here on local VHF BBS,
- because the nearest one located abt 200 km from here.
- So it is only one way to find it - this place.
-
- Thank's
- Andrey Petrov, UA1TFA.
-
- Russia
- Novgorod State University
- pap@pltx.nov.su
-
- ------------------------------
-
- Date: Mon, 4 Apr 1994 21:20:57 GMT
- From: amd!news.kpc.com!kpc!nat@decwrl.dec.com
- Subject: CDE antenna rotor
- To: ham-digital@ucsd.edu
-
- Hi,
- I bought a CDE antenna rotor at a hamfest last year. The rotor is
- fine but the controller seems to be flaky when I try to point the antenna
- between N and West. Here are the details from the back of the controller.
-
- Model AR-33 115 V.A.C
- 60 cycle 1 Amp
- Mfd by
- Cornell-Dubilier
- Electronics Div.
- Federal Pacific Electric Co.
- Fuquay-Varina, North Carolina.
- Patent No. 3.043,998
-
- Series 1820.
-
- The terminal strip has 5 wires. If anybody has a copy of the schematics
- of the controller I'd like to get a copy of it. Could some knowledgeable soul
- explain how the 5 wire system works. I opened the controller and the
- position dial is nice wire wound resistor of 1K ohm resistance which has
- been hooked up as a variable resistor and not a potential devider. There is
- a large capacitor across terminal 1 and 5. There is a transfromer with a
- center tapped secondary. The outer terminals are connected to terminals 2 and 4.
- Voltage between one of the outer terminals and the center tap is 14.2 volts.
- The center tap is connected to a ground trace on the circuit board.
-
- Is the controller setup as a bridge where the dial in the controller
- is one of the arms and a similar dial up in the rotor is the other arm.
- The rotor stops moving when the 2 arms get balanced. Any information will be
- of great help
-
- Sincerely
- Nat.
-
- --
- -------------------------------------------------------------------------
- Natarajan Gurumoorthy AB6SJ Kubota Pacific Computer, Inc.
- nat@kpc.com 2630 Walsh Avenue
- Phone 408 987 3341 Santa Clara, California 95051.
-
- ------------------------------
-
- Date: Mon, 4 Apr 1994 20:16:30 GMT
- From: agate!howland.reston.ans.net!wupost!crcnis1.unl.edu!news.unomaha.edu!news.nevada.edu!jimi!envoy!jim@ames.arpa
- Subject: Heathkit HD-15 Phonepatch Manual?
- To: ham-digital@ucsd.edu
-
- I recenly aquired a Heath HD-15 phone patch without a manual. Is there
- someone who would make a copy for me? I will gladly pay expenses. Thank
- you very much.
-
-
- --
- -------------------------------------------------------------------------------
- Jim Mueller | Work : (702) 689-3111 | jim@shadow.scs.unr.edu
- 11865 Deodar Way | Home : (702) 677-2775 | WB7AUE@KE7KD.#NONEV.NV.USA.NOAM
- Reno, NV 89506 | |
-
- ------------------------------
-
- Date: 5 Apr 1994 03:01:12 GMT
- From: ihnp4.ucsd.edu!agate!howland.reston.ans.net!gatech!newsxfer.itd.umich.edu!news1.oakland.edu!chaos!ron@network.ucsd.edu
- Subject: JNOS and SAM
- To: ham-digital@ucsd.edu
-
- John Martin (martin@server.cdpa.state.ms.US) wrote:
- : One other problem though. The command prompt is not cleared (ie, it still
- : contains the command just entered) whenever the command causes you to
- : switch to another session. When I return to the console screen the previous
- : command is still on the command line following the prompt. The command IS
-
- Look on some archive sites for a patch for Borland C++ 2.0. This sounds just
- like the problem that one of their library files had. I used to have to put
- the patch on it when I ran 2.0, I'm running Borland C++ 3.1 now and it
- works fine.
-
- : 73 - John
-
- 73 Ron N8FOW
-
- ------------------------------
-
- Date: 5 Apr 94 03:00:58 GMT
- From: dog.ee.lbl.gov!agate!howland.reston.ans.net!vixen.cso.uiuc.edu!prairienet.org!k9cw@ucbvax.berkeley.edu
- Subject: MFJ 120C & Netrom
- To: ham-digital@ucsd.edu
-
- In a previous article, chuckv@comtch.iea.com (Chuck Vyverberg) says:
-
- >I saw some messages the last couple fo week giving detailed instructions
- >on how to get the MFJ1270C TNC to run as a netrom node.
- >
-
- To use the MFJ1270C with netrom or TheNET, all you need to do is program
- a 27256 EPROM with the modified firmware module (V2.08B is the one I have
- in three digi's in central IL) and plug it in. No circuit mods are
- required.
-
- Installing an X1J node is another matter...
-
- 73, Drew
-
- --
- *-----------------------------*-------------------------------------*
- | Andrew B. White K9CW | internet: k9cw@prairienet.org |
- | ABW Associates, Ltd. | phone/fax: 217-643-7327 |
- *-----------------------------*-------------------------------------*
-
- ------------------------------
-
- Date: Mon, 4 Apr 1994 16:18:29 GMT
- From: rit!sunsrvr6!jdc@cs.rochester.edu
- Subject: Unknown RTTY mode
- To: ham-digital@ucsd.edu
-
- In article <wilsonjhCnGKA1.Ix4@netcom.com>,
- John Wilson <wilsonjh@netcom.com> wrote:
- >I have been monitoring some "utility" signals using an AEA PK232-MBX,
- >and have run across many strong signals that the PK232 cannot decode.
- >These sound like ordinary two-tone FSK RTTY signals.
- >They are often, but not always in the HF maritime bands (6, 8, 12, etc.
- >Mhz), and the signal identification feature on the PD232 shows
- >75 baud and mode "unknown". I hear these signals with both narrow
- >and wide shifts. Anybody know what they are? A special code for an
- >Oriental language? Encrypted data? Something altogether else? Anybody
- >know how to copy them?
- >
- >Tnx es 73,
- >John K3KXJ
-
- I have also run into these signals. I always thought the inability
- to decode them was due to shortcomings in hardware interface and
- software. (I use Hamcom 2.2 with the 741 op-amp interface.) But
- this may not be the case.
-
- After receiving the last half of a weather-fax map, the station switched
- to RTTY. It was strong signal, and the weather-fax came in OK. After
- it switched to RTTY I fired up Hamcom 2.2. It was easy to figure out
- frequency shift and baud rate with the "Spectrum" and "Bit length"
- screens. But the text was undeciperable gobbledygook.
-
- Seems like it must be some type of maritime-related station. Anybody
- have more specific info?
-
- 73...Jim N2VNO
-
- ------------------------------
-
- Date: Mon, 4 Apr 1994 22:17:24 GMT
- From: ihnp4.ucsd.edu!library.ucla.edu!europa.eng.gtefsd.com!uhog.mit.edu!news.mtholyoke.edu!world!dts@network.ucsd.edu
- To: ham-digital@ucsd.edu
-
- References <2nejic$j75@hp-col.col.hp.com>, <CnJL6K.Loq@world.std.com>, <2nph5e$djt@hpbab.mentorg.com>.mthol
- Subject : Re: NTS traffic on packet
-
- In article <2nph5e$djt@hpbab.mentorg.com> Hank_Oredson@mentorg.com writes:
- >In article <CnJL6K.Loq@world.std.com>, dts@world.std.com (Daniel T Senie) writes:
- >|> In article <2nejic$j75@hp-col.col.hp.com> jms@col.hp.com (Mike Stansberry) writes:
- >|> >Jeffrey D. Angus (jangus@skyld.grendel.com) wrote:
- >
- >|> I have lately seen traffic duplicated 2 or 3 times. One message I sent to
- >|> my STM at the other end of the section got there 4 times. We have had
- >|> a rash of multiple NTS deliveries.
- >
- >This is a very serious problem.
- >
- >There are many possible causes, but they all come down to poor operating
- >practices by the sysops. If the sysops had things set up reasonably,
- >and made certain their systems were operating properly, then there would
- >be no (zero, zilch, none) duplicated bulletins.
- >
- >Personal messages and NTS traffic are handled differently.
- >Duplicates are allowed to occur, rather than lose an occasional message.
- >However, these duplicates should be rare: 1 in 1000 perhaps.
-
- This raises some alarm bells with me. Networks need to either send or not
- send messages. Protocols are designed to be able to be sure of such things.
- Could you imagine if something like an international money transfer were
- occasionally duplicated on the commercial networks? It sounds like the
- protocols involved (in nthis case, the handling methods) may need some
- review.
-
- Why is the software designed to allow even an occasional duplicate? Why
- is there otherwise the possibility of a lost message?
-
- >
- >Sounds like the sysops involved have not done a very good job of
- >getting their systems to work.
- >
- >You can't just "Load the BBS software and away you go."
- >It takes thought, planning, cooperation, and coordination to make a network
- >work properly. In the past couple years, I have noticed a distinct lack of
- >all of the above in many parts of the BBS network.
- >
- >Perhaps time for some organization to take a leadership postion here?
- >
- >(ARRL, where are you when you are needed?)
-
- Well, I am the local ARRL person (Section Manager). I'm gathering information
- so that I can intelligently address the appropriate people about the
- problem.
-
- In this area the North East Digital Association runs the AX.25 net, so it
- would seem to make sense that they are the ones to take the leadership
- position on this. Perhaps I need to appoint an Assistant Section Manager
- who can oversee packet operations, or something like that...
-
- >
- > ... Hank
- >
- >--
- >
- >Hank Oredson @ Mentor Graphics
- >Internet : hank_oredson@mentorg.com
- >Amateur Radio: W0RLI@W0RLI.OR.USA.NOAM
-
- Thanks for your response, by the way. I do appreciate that you and others
- put in quite a bit of time on the BBS software. Overall things seem to work
- pretty well, but it gives a false sense of security sometimes, when things
- like the multitude of dupes we've seen happen.
-
- thanks and 73,
-
- Dan N1JEB SM WMA
- --
- ---------------------------------------------------------------
- Daniel Senie Internet: dts@world.std.com
- Daniel Senie Consulting n1jeb@world.std.com
- 508-779-0439 Compuserve: 74176,1347
-
- ------------------------------
-
- Date: Mon, 4 Apr 1994 22:24:16 GMT
- From: spsgate!mogate!newsgate!dtsdev0!kinzer@uunet.uu.net
- To: ham-digital@ucsd.edu
-
- References <2nejic$j75@hp-col.col.hp.com>, <CnJL6K.Loq@world.std.com>, <2nph5e$djt@hpbab.mentorg.com>ev0
- Subject : Re: NTS traffic on packet
-
-
- All I can say is I'm glad no one is charged with maintaining the
- ionosphere. Just imagine the bitching out they'd get.
-
- I do have one positive contribution to make. If duplicate messages are
- really a big problem, then each (or each destination) node could keep a
- hash code of the content of every message that has been seen in the past
- N days. If any hash code matches, delete the message without passing
- it along or making it available for download. Ignoring headers allows
- messages that have taken different routes to still be zapped. Using a
- good hash and enough bits and enough days history you could select the
- probability of erroneously dropping a non-duplicate to less than the
- probability of an NTS operator accepting a message yet dying before he
- delivers it.
-
- Say 12 bits for date received (would allow over 10 years of data to
- accumulate and still allow for deleting by day, talk about overkill) and
- 52 bits of hash for a total of 8 bytes retained per message. If 100
- messages arrived daily, and we kept 120 days worth, we would be keeping
- 96K bytes of data, not even a floppy disk worth. There would be 12,000
- hash patterns (no duplicates) from a data space of 2^52, giving the
- possibility of erroneously deleting a random incoming message of
- 0.000000000266 percent. Add a few more bits to the hash code if that's
- not good enough for you. Even as it is, at 100 messages daily, it means
- only one dropped message every 10 million years on average. I don't think
- this will be the weak link in delivering messages.
-
- Of course, I don't claim to be a mathematician or statistician, so the
- above numbers should be taken as a general approximation at best. Still,
- it's one avenue open for exploration.
-
- -dave
-
- ------------------------------
-
- Date: 5 Apr 1994 02:20:07 GMT
- From: nothing.ucsd.edu!brian@network.ucsd.edu
- To: ham-digital@ucsd.edu
-
- References <2n7bup$3v3@hpbab.mentorg.com>, <1994Mar29.100554.3059@hemlock.cray.com>, <2nphhd$djt@hpbab.mentorg.com>
- Subject : Re: [REPOST] The # in PBBS addresses....
-
- In article <2nphhd$djt@hpbab.mentorg.com> Hank_Oredson@mentorg.com writes:
- >You are perhaps talking about the internet, which chose to ignore
- >the existing use of NA in one of it's connected networks?
-
- Oh jeez, Hank, stop making things up. The AMPR.ORG domain has never used
- the ham bbs hierarchical routing/addressing scheme to name hosts.
-
- With some exceptions, the namespace of the AMPR.ORG domain consists
- solely of callsigns within the domain. Names are not routes, routes
- are not names, and mixing them up is one of the worst possible mistakes
- a network architect could make.
-
- That means that whilst you might see
- W0RLI.AMPR.ORG
- or
- BBS.W0RLI.AMPR.ORG
- you won't see
- W0RLI.#NNJ.NJ.USA.NOAM.AMPR.ORG
- or the like
-
- Ever.
- - Brian
-
- ------------------------------
-
- End of Ham-Digital Digest V94 #98
- ******************************
-